home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet E-Mail Workshop
/
Internet E-Mail Workshop.iso
/
info
/
mudfaq.
< prev
next >
Wrap
Text File
|
1993-11-24
|
73KB
|
1,362 lines
FREQUENTLY ASKED QUESTIONS: Basic Information about MUDs and MUDding
This is part 1 in a 3 part series of FAQs.
Disclaimer - This document may be seen to be biased towards TinyMUDs.
This is because the maintainer mainly plays those types of
servers, not because she thinks they are inherently better
or worse than other types of servers. However, this document
is meant to be generalized and useful for all MUDdom, and
so corrections and contributions are always welcome.
Welcome to the world of MUDding!
Table of Contents
-----------------
FAQ #1: Basic Information about MUDs and MUDding
General Information
1. What is a MUD?
2. What different kinds of MUDs are there?
3. Where are MUDs located?
4. I paid money for my account! MUDding is a right, isn't it?
5. How do I connect to a MUD?
6. What is a client program?
7. Now that I'm connected, what do I do?
8. Why not just dive in?
9. What password should I use for my MUD character?
10. What's the easiest way to annoy a veteran MUD user?
11. What's the easiest way to be a mean veterean MUD user?
12. What should I _not_ do in terms of player interaction?
13. Is MUDding a game, or an extension of real life with gamelike
qualities?
14. What common commands are used on MUDs?
15. I know what's going on now! What's next?
16. Who should I ask for help?
17. What if I'm completely confused and am casting about for a rope
in a vast, churning wilderness of chaos and utter incomprehension?
18. What USENET newgroups are devoted to MUDs?
19. How do I start my own MUD?
Glossary
20. What was the first MUD?
21. What is a bot?
22. What's a clueless newbie?
23. What is a cyborg?
24. What's a dino?
25. What is a flame?
26. What is a furry?
27. What is HAVEN?
28. What is a log?
29. What is Maving?
30. What is net lag?
31. What's player killing?
32. What is spam?
33. What is TinySex?
34. What is a 'Wizard' or 'God'?
FAQ #2: MUD Clients and Servers
Client Information
1. What is a client?
2. Where do I get clients?
3. What operating systems do clients run on?
4. Is there anything wrong with running a client?
5. What different clients are available? [Client List]
Glossary of Client terms
Server Information
6. What is a server?
7. Where do I get servers?
8. What operating systems to servers run on?
9. Is there anything wrong with running a server?
10. What different servers are available? [Server List]
General Information
11. What do I do if my client/server won't compile?
12. Should I read the documentation of whatever client or server
I select?
13. What is FTP, and how do I use it?
FAQ #3: Basic Information on RWHO and "mudwho"
1. What is RWHO?
2. How Does It All Work?
3. Where Can I Get This Stuff?
4. Where Are Some RWHO Servers?
General Information
1. What is a MUD?
A MUD (Multiple User Dimension, Multiple User Dungeon, or Multiple User
Dialogue) is a computer program which users can log into and explore.
Each user takes control of a computerized persona/avatar/incarnation/
character. You can walk around, chat with other characters, explore
dangerous monster-infested areas, solve puzzles, and even create your
very own rooms, descriptions and items. You can also get lost or confused
if you jump right in, so be sure to read this document before starting.
2. What different kinds of MUDs are there?
You'll notice the disclaimer on this FAQ mentions TinyMUD. That's
one common type of MUD, but there are many different types of MUDs
out there. The Tiny- and Teeny- family of MUDs are usually more
'social' in orientation; the players on those MUDs tend to gather,
chat, meet friends, make jokes, and discuss all kinds of things.
The LP- family of MUDs, including Diku and AberMUD, are usually
based on roleplaying adventure games; the players on those MUDs
tend to run around in groups or alone killing monsters, solving
puzzles, and gaining experience in the quest to become a wizard.
There are still other types of MUDs, such as MOOs, UnterMUDs,
and so forth. Each type has its own unique style, and players
are rarely forced to stick to one type of playing - there's no
rule that says an LPMUD _must_ be a combat-oriented MUD, or
that a TinyMUSH _must not_ be a combat-oriented MUD. We suggest
that you experiment around with several different types of MUDs
to see what you find is the most interesting. If there's one thing
MUDdom has, it's variety.
3. Where are MUDs located?
Watch the USENET newsgroup rec.games.mud.announce. Every Friday a quite
complete listing of MUDs is posted. If you can't wait till Friday, you can
email mudlist@glia.biostr.washington.edu and ask for one, or they're
available for FTP from caisr2.caisr.cwru.edu(129.22.24.22) in /pub/mud.
MUDs are run on many fine computers across the world. To play, all you
have to do is telnet to the MUD's Internet Protocol Port, and you're in
business. Some MUDs have a policy called "registration" to cut down on
abuse of privileges; you might have to send mail to the administrator of
the MUD in order to obtain a character. It's important to note that MUDs
are *not* a right, and your access is granted out of trust. People usually
have to pay to use processing time on the large, expensive computers which
MUDs often run on, and you're being given a special deal. Which brings
us to another point: MUDs can't really be run on anything less than a
largish workstation (currently), so they're usually on academic or
corporate workhorse machines.
4. I paid money for my account! MUDding is a right, isn't it?
Don't believe that for a second. When you paid money to your school's
computer department for an account, you entered into a contract with
that department. Most schools have a well written Computer Policy
document, that will detail exactly what you have rights to. Most
schools classify MUD as a game, and games as non-essentials. Therefore,
if your school decides to shut off all games, or disallow you to telnet
out to play muds, you're stuck. Don't try to get around it; they'll
find you. Instead, try to talk to the Powers That Be, and see why they
did what they did. They may have very good reasons for it (such as
limited resource that really need to be dedicated to schoolwork).
5. How do I connect to a MUD?
There are several ways to hook yourself up to a MUD's internet port. First,
you can use 'telnet' once you find out the MUD's network address and port
number. If, for instance, we knew that ChupsMUD was at the network address
'pickle.cs.umsst.edu' at port 4201, we could type:
(on most systems, including UNIX)
telnet pickle.cs.umsst.edu 4201
(or, on some VMS systems)
telnet pickle.cs.ummst.edu/port=4201
and we'd be ready for action. If we get back an error saying something like
"host unknown", we'd want to do the same thing, only using the machine's
internet number address, like this: telnet 127.0.0.1 4201. If you're using
straight telnet on a VMS system, you might have to make sure that your
terminal has "newlines" turned on. If it doesn't, the mud's output will get
spewed across the screen in a most ugly fashion.
Your second option is to scout out the many fine client programs which
exist for the sole purpose of providing a friendly and useful front end
to MUDs. (See 'client', below.)
6. What is a client program?
Telnet is a rather ugly way to connect to most muds, since it doesn't
do any fancy text wrapping, and if someone says something while you're
typing out a line, it will make a mess out of your line, making it
hard to see what you're typing and hard to keep track of what's going
on in the mud. A client program is simply another program you use instead
of telnet to connect to a mud. Clients also provide useful things such
as macros and the ability to gag or highlight certain mud output. Clients
are available for anonymous ftp from several sites. See the Frequently
Asked Questions posting #2 for more information about clients.
7. Now that I'm connected, what do I do?
Once you connect, find out what the deal is with respect to you getting
a character. Some MUDs allow you to create your own, and others require
you to send off for one via email. If you have to send off for one, send
one e-mail request and cool your heels. MUDding will be around forever,
no need to rush it. But let's say you've now gotten a character, and you're
connected up, and things are starting to get interesting. At this point,
you should do what is probably least intuitive: type 'help', read the
instructions and directions, and understand them. Then, type 'news',
read the information, and understand it. Then (yes, we know, we know...
it'll be fun, soon!) practice using the commands given to you until
you think you've got a good enough grip to be able to start in on
exploring, questing, socializing, or whatever else tunes your engine.
8. Why not just dive in?
Some people are easily annoyed when other people clearly have no idea what
they are doing, even if they were recently in that position themselves.
It'll be much easier for you to cope without some fella saying things
you don't understand to you and possibly killing you. *However*, many
MUD players are helpful, and asking them, "excuse me, are you busy? I'm
a brand new player, and I have a question," will often work just fine.
9. What password should I use for my MUD character?
You should pick a password just as you do for any computer account. Use a
word, or better yet, a phrase or anagram, that isn't obvious. Don't, for
instance, use the same name as your character, or your own first name, or
your girl/boyfriend's name. And never never use the same password as the
one on your computer account. Most MUDs prevent people from getting the
passwords from within the mud, and most encrypt the password when it's
store in the database files. However, there is nothing preventing the
MUD's owner from modifying the code to dump the passwords to a file, along
with other information such as the host you connected from. Using this
information, an evil MUD admin could probably figure out your login name
and get into your account easily. It's also not a good idea to use the
same password on different MUDs, since if your password gets out on one
MUD, all your MUD characters have been compromised. This is ESPECIALLY
important for MUD Wizards and Gods. Use the auto-login feature of your
client, if it has one, and protect the file containing the login information
against reading by others.
This story comes from Alec Muffett, author of Crack and maintainer of the
alt.security FAQ.
aem@aberystwyth.ac.uk: The best story I have is of a student
friend of mine (call him Bob) who spent his industrial year at
a major computer manufacturing company. In his holidays, Bob
would come back to college and play AberMUD on my system.
Part of Bob's job at the company involved systems management,
and the company was very hot on security, so all the passwords
were random strings of letters, with no sensible order. It was
imperative that the passwords were secure (this involved writing
the random passwords down and locking them in big, heavy duty safes).
One day, on a whim, I fed the MUD persona file passwords into
Crack as a dictionary (the passwords were stored plaintext)
and then ran Crack on our systems password file. A few student
accounts came up, but nothing special. I told the students
concerned to change their passwords - that was the end of it.
Being the lazy guy I am, I forgot to remove the passwords from
the Crack dictionary, and when I posted the next version to
USENET, the words went too. It went to the comp.sources.misc
moderator, came back over USENET, and eventually wound up at
Bob's company. Round trip: ~10,000 miles.
Being a cool kinda student sysadmin dude, Bob ran the new version
of Crack when it arrived. When it immediately churned out the
root password on his machine, he damn near fainted...
The moral of this story is: never use the same password in two
different places, and especially on untrusted systems (like MUDs).
10. What's the easiest way to annoy a veteran MUD user?
Demand something. Whine. Follow them around. Page or tell them over
and over after they've asked you to stop. In combat MUDs, steal
from corpses of things they just killed.
11. What's the easiest way to be a mean veterean MUD user?
Don't give help to the new players. Kill them, ignore them, shout
"get a description" at them. These are the best ways to kill off MUDding
in general, actually.
12. What should I _not_ do in terms of player interaction?
You shouldn't do anything that you wouldn't do in real life, even if the
world is a fantasy world. The important thing to remember is that it's
the fantasy world of possibly hundreds of people, and not just yours in
particular. There's a human being on the other side of each and every
wire! Always remember that you may meet these other people some day,
and they may break your nose. People who treat others badly gradually
build up bad reputations and eventually receive the NO FUN Stamp of
Disapproval. The jury is still out on whether MUDding is "just a game"
or "an extension of real life with gamelike qualities", but either way,
treat it with *care*.
13. Is MUDding a game, or an extension of real life with gamelike qualities?
It's up to you. Some jaded cynics like to laugh at idealists who think
it's partially for real, but we personally think they're not playing it
right. Certainly the hack-'n-slash stuff is only a game, but the social
aspects may well be less so.
14. What common commands are used on MUDs?
Most MUDS have a core of commands which players use to move around and
interact with each other. For instance, there are commands for interacting
with other players, like 'say' (or sometimes '"'), and other commands like
'look', 'go', etc. In TinyMUD, there are commands like 'home' (which always
places you in your home -- remember that), ':' (pose -- try it), etc.,
which allow you to do stuff inside the database. Commands prefixed by
a @ (generally) allow you to change the database! Commands like @describe,
@create, @name, @dig and @link allow you to expand the universe, change it,
or even, perhaps, @destroy it, under certain conditions. In LPMUDs, none of
those apply; in order to edit the universe, you have to attain Wizardhood or
be the God of the MUD. Whatever the case, these building commands are
beyond the scope of this little sheet -- find the documentation for whatever
MUD you're playing with and consume it avidly. Most MUDs have documentation
on-line, although better documentation can be gotten via ftp from other
sites. Ask around, or try looking on ftp.tcp.com (128.111.72.60),
or ftp.math.okstate.edu (139.78.10.6) in /pub/muds/misc.
15. I know what's going on now! What's next?
Now is the time when you should be most careful. Within reason,
don't be afraid to ask questions of other players.
16. Who should I ask for help?
Wizards (see the glossary section) are usually helpful; if you know a
wizard to be a wizard, then you can usually ask them a question or two.
Make sure they're not busy first. Also, players who have been logged on
for a long time (which you can check using the WHO command) are often
helpful, as they are usually the veterans who've seen it all before.
In combat MUDs, asking relatively high level characters is usually the
way to find things out.
17. What if I'm completely confused and am casting about for a rope in a
vast, churning wilderness of chaos and utter incomprehension?
Ask a friend to help you. Don't post anything in any newsgroup. Just
take it slow, one step at a time, smoothing over the things you don't
understand by reading manuals (i.e. 'man telnet'), asking local help,
or trying to find people who use MUDs who are at your site.
18. What USENET newgroups are devoted to MUDs?
There are several USENET newsgroups associated with MUDs. The first (and
least used) is alt.mud. When it got popular, the newsgroup rec.games.mud
was then created, and when it got too noisy and chaotic, a few new groups
were split off of the main one (rec.games.mud is no longer a "real"
newsgroup - all of its volume went to rec.games.mud.misc). The current
newsgroups are:
rec.games.mud.admin - Postings pertaining to the administrative
side of MUDs.
rec.games.mud.announce - moderated group, where announcements of
MUDs opening, closing, moving, partying,
etc are posted.
rec.games.mud.diku - Postings pertaining to DikuMUDs.
rec.games.mud.lp - Postings pertaining to LPMUDs.
rec.games.mud.misc - Miscellaneous postings.
rec.games.mud.tiny - Postings pertaining to the Tiny* family
of MUDs.
If you feel you must post something to USENET, please do it in the
group where it best belongs - no posts about TinyMUSH in the Diku
group, no questions about an LPMUD in the Tiny group, etc.
19. How do I start my own MUD?
First, you need to pick a server. You'll have to figure out how to
compile it, get it running, and you'll need to know how to _keep_ it
running, which usually involves some programming skills, generally in
C, and a good deal of time. Of course, you also need to be well versed
in the ways and commands of that particular MUD server, and you'll
probably need help running the place from a few of your friends.
Don't forget that you'll have to have a machine to run it on, and the
resources with which to run it. Most MUDs use anywhere from 5 to 90
megs of disk space, and memory usage can be anything from 1 to 35 megs.
A good rule of thumb is to first ask around for specifics on that server;
average muds need around 25 megs of disk space for everything, and about
10 megs of memory, although the exact numbers vary widely.
NOTE: If you don't *explicitly own* the machine you're thinking about
right now, you had better get the permission of the machine owner before
you bring up a MUD on his computer. MUDs are not extremely processing-
consumptive, but they do use up some computing power. You wouldn't want
people plugging in their appliances into the outlets of your home without
your permission or knowledge, would you?
Glossary of MUD Terms
20. What was the first MUD?
MUD1, written by Richard Bartle and Roy Trubishaw, back in 1979-80, is
generally accepted as the first MUD. TinyMUD Original, the first of
the Tiny- family of muds, was written in August 1989. A more complete
chronology of MUDs is being prepared - contributions emailed to
jds@math.okstate.edu are heartily welcomed.
21. What is a bot?
A bot is a computer program which logs into a MUD and pretends to be a
human being. Some of them, like Julia, are pretty clever -- legend has it
that Julia's fooled people into believing that she's human. Others have
less functionality. The most common bot program is the Maas-Neotek model.
22. What's a clueless newbie?
A 'newbie' is someone who has only recently begun to participate in some
kind of activity. When we're born, we're all life newbies until we get
experience under our belts (or diapers, whatever). You're a clueless
newbie until you've got the hang of MUDding, basically.
23. What is a cyborg?
A cyborg is defined as 'part man, part machine.' In the MUD world, this
means that your client is doing some of the work for you. For instance,
you can set up many clients to automatically greet anyone entering the
room. You can also set up clients to respond to certain phrases (or
'triggers'). Of course, this can have disastrous consequences. If
Player_A sets his client up to say hi every time Player_B says hi, and
Player_B does likewise, their clients will frantically scream hi at each
other over and over until they manage to escape. Needless to say, runaway
automation is very heavily frowned upon by anyone who sees it. If you
program your client to do anything special, first make sure that it cannot
go berserk and overload the MUD.
24. What's a dino?
A dino is someone that has been around for a very long time (cf. 'dinosaur').
These people tend to reminisce nostalgically about dead or nonexistent
MUDs which were especially fun or interesting.
25. What is a flame?
Flaming is when someone shouts at another person in a vain attempt to
convince them that whatever that other person said or believes in is
unconditionally wrong or stupid. Avoid getting into flame wars, and
if flamed, laugh it off or ask someone else what you did wrong.
26. What is a furry?
A 'furry' is an anthropomorphic intelligent animal. If you've ever
seen Zoo-bilee Zoo on The Learning Channel, you know what I mean.
Furries are not unique to MUDdom - they originated in comics, and
can usually be found at comic or animation conventions and the like.
Generally, any MUD character which has fur and is cute is deemed a
furry. Most furries hang out on FurryMUCK, naturally.
27. What is HAVEN?
On many TinyMUDs, there are several flags associated with each room. The
HAVEN flag is probably the most famous one. In rooms where the HAVEN flag
is set, no character may kill another. (See 'player killing' below.)
28. What is a log?
Certain client programs allow logs to be kept of the screen. A time-
worn and somewhat unfriendly trick is to entice someone into having
TinySex with you, log the proceedings, and post them to rec.games.mud.*
and have a good laugh at the other person's expense. Logs are useful
for recording interesting or useful information or conversations, as well.
29. What is Maving?
Mav is a famous TinyMUDder who sometimes accidentally left a colon on
the front of a whisper, thus directing private messages to the whole
room. The meaning of the verb has changed to include making any
say/whisper/page/pose typing confusion.
30. What is net lag?
The Internet (the network which connects your computer to mine) is made
up of thousands of interconnected networks. Between your computer and
the computer which houses the MUD, there may be up to 30 gateways and
links connecting them over serial lines, high-speed modems, leased lines,
satellite uplinks, etc. If one of these gateways or lines crashes, is
suddenly overloaded, or gets routing confused, you may notice a long
time of lag time between your imput and the MUD's reception of that
input. Computers which are nearer to the computer running the MUD are
less susceptible to netlag. Another source of lag is if the computer
which hosts the MUD is overloaded. When netlag happens, it is best to
just patiently wait for it to pass.
31. What's player killing?
The answer to this question varies widely. On most combat-oriented
MUDs, such as LPMUD and Diku, player killing is taken quite seriously.
On others, it's encouraged. On most TinyMUDs, as there is little to
no combat system, player killing is sometimes employed as a means of
showing irritation at another player, or merely to show emphasis of
something said (usually, it means "and I really mean it!"). It's
best to find out the rules of the MUD you're on, and play by them.
32. What is spam?
Spamming, derived from a famous Monty Python sketch, is the flooding of
appropriate media with information (such as repeated very long 'say'
commands). Unintentional spamming, such as what happens when you walk
away from your computer screen for a few minutes, then return to find
several screenfuls of text waiting to scroll by, is just a source of
irritation. Intentional spamming, such as when you repeat very long
'say' commands many times, or quote /usr/dict/words at someone, is
usually frowned on, and can get you in trouble with the MUD administration.
33. What is TinySex?
TinySex is the act of performing MUD actions to imitate having sex
with another character, usually consentually, sometimes with one hand
on the keyboard, sometimes with two. Basically, it's speed-writing
interactive erotica. Realize that the other party is not obligated
to be anything like he/she says, and in fact may be playing a joke
on you (see 'log', above).
34. What is a 'Wizard' or 'God'?
Gods are the people who own the database, the administrators. In most
MUDs, Wizards are barely distinguishable from Gods - they're just barely
one step down from the God of the MUD. An LPMUD Wizard is a player who
has 'won' the game, and is now able to create new sections of the game.
Wizards are very powerful, but they don't have the right to do whatever
they want to you; they must still follow their own set of rules, or face
the wrath of the Gods. Gods can do whatever they want to whomever they
want whenever they want - it's their MUD. If you don't like how a
God acts or lets his Wizards act toward the players, your best recourse
is to simply stop playing that MUD, and play another.
A more appropriate name for wizards would probably be 'Janitor', since
they tend to have to put up with responsibilities and difficulties (for
free) that nobody else would be expected to handle. Remember, they're
human beings on the other side of the wire. Respect them for their
generosity.
FREQUENTLY ASKED QUESTIONS: MUD Clients and Servers
This is part 2 in a 3 part series of FAQs.
Disclaimer - This document may be seen to be biased towards TinyMUDs.
This is because the maintainer mainly plays those types of
servers, not because she thinks they are inherently better
or worse than other types of servers. However, this document
is meant to be generalized and useful for all MUDdom, and
so corrections and contributions are always welcome.
Table of Contents
-----------------
Client Information
1. What is a client?
2. Where do I get clients?
3. What operating systems do clients run on?
4. Is there anything wrong with running a client?
5. What different clients are available? [Client List]
Glossary of Client terms
Server Information
6. What is a server?
7. Where do I get servers?
8. What operating systems to servers run on?
9. Is there anything wrong with running a server?
10. What different servers are available? [Server List]
General Information
11. What do I do if my client/server won't compile?
12. Should I read the documentation of whatever client or server
I select?
13. What is FTP, and how do I use it?
Client Information
1. What is a client?
Clients are programs, usually written in C, that connect up to
servers. Telnet is one such client program. Many clients written
for MUDs have special added bonus features through which they filter
the output; most, for instance, separate your input line from the
output lines and wraps words after 80 columns. Some also have a macro-
writing capability which allows the user to execute several commands with
just a few keypresses. Some allow you to highlight output coming from
certain players or suppress it altogether. Still other clients make
the sometimes tedious task of building new areas a breeze.
2. Where do I get clients?
Listed below is a list of clients, and a site or two where they can
be ftped from. If the site is down, your best bet is to ask around.
In general, ftp.tcp.com (128.111.72.60) and ftp.math.okstate.edu
(139.78.10.6) are good places to look. Directions for how to ftp
and unarchive clients are at the end of this FAQ.
3. What operating systems do clients run on?
Most use BSD Unix, although many also run under SysV Unix. Some run under
VMS with either MultiNet or Wollongong networking, a few new ones run
on a Macintosh, and there's even one for IBM VM.
4. Is there anything wrong with running a client?
Not usually. Clients can be large when compiled, especially if they
have lots of nifty features. They don't take up much CPU time at all.
It is recommended that you ask your friendly systems administrator or
other machine-responsible person if it's okay for you to install one
on the system, if only for the reason that someone else might already
have done so, and you might be able to save space by sharing with them.
If there's a no games policy at your site, don't try to sneak by it with
a client -- their activities are easily detectable. Be good.
5. What different clients are available?
Here's a reasonably accurate listing of available clients. Please note
that I have not tested each of these, and they're not guaranteed to
work for you. If your favorite client isn't listed here, please
drop a short note describing the client's features and where it can
be ftp'd from to jds@math.okstate.edu.
UNIX clients appear first, VMS clients next, miscellaneous clients last.
EMACS clients for UNIX appear after those written in C.
Directions for how to ftp and unarchive clients and servers can be found
at the end of this FAQ.
Name Description
---- -----------
TinyTalk Runs on BSD or SysV with networking. Latest version is
1.1.7GEW. Designed primarily for TinyMUD-style muds.
Features include line editing, command history,
hiliting (whispers, pages, and users), gag, auto-login,
simple macros, logging, and cyberportals.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
parcftp.xerox.com(13.1.64.94):/pub/MOO/clients
ftp.tcp.com(128.111.72.60):/pub/mud/clients
TinyFugue Runs on BSD or SysV with networking. Latest version is
3.0alpha20. Commonly known as 'tf'. Designed primarily for
TinyMUD-style muds, although will run on LPMUDs and Dikus.
Features include regexp hilites and gags, auto-login, macros,
line editing, screen mode, triggers, cyberportals, logging,
file and command uploading, shells, and multiple connects.
ftp.tcp.com(128.111.72.60):/pub/mud/clients
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
TclTT Runs on BSD. Latest version is 0.9. Designed primarily for
TinyMUD-style muds. Features include regexp hilites, regexp
gags, logging, auto-login, partial file uploading, triggers,
and is programmable.
ftp.white.toronto.edu(128.100.2.160):/pub/muds/tcltt
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
VT Runs on most BSD and SysV UNIX systems. Latest version
is 2.15. Must have vt102 capabilities. Useable for all
types of muds. Features include a C-like extension language
(VTC) and a simple windowing system.
ftp.math.okstate.edu(139.78.1.12):/pub/muds/clients/vt
ftp.tcp.com(128.111.72.60):/pub/mud/clients
LPTalk Runs on BSD or SysV with networking. Latest version is 1.2.1.
Designed primarily for LPMUDs. Features include hiliting,
gags, auto-login, simple macros, logging.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
SayWat Runs on BSD. Latest version is 0.23. Designed primarily for
TinyMUD-style muds. Features include regexp hilites,
regexp gags, macros, triggers, logging, cyberportals,
rudimentary xterm support, command line history,
and file uploading.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
PMF Runs on BSD. Latest version is 1.12.1. Usable for both LPMUDs
and TinyMUD-style muds. Features include line editing,
auto-login, macros, triggers, gags, logging, file uploads,
an X-window interface, and ability to do Sparc sounds.
ftp.lysator.liu.se(130.236.254.1):/pub/lpmud/clients
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
TinyView Runs on BSD. Latest version is 1.0. Designed for use primarily for TinyMUD-style muds. Features include screen mode, macros,
history buffers, line editing, and multiple connects.
NO KNOWN SITE
TINTIN Runs on BSD. Latest version is 3.0. Designed primarily
for Dikus. Features include macros, triggers,
tick-counter features, and multiple connects.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
ucbvax.berkeley.edu(128.32.133.1):/pub/games/dikumud/utility
TUsh Runs on BSD and SysV with networking. Latest version
is 1.74. Features include hiliting, triggers, aliasing,
history buffer, and screen mode.
ftp.warwick.ac.uk(137.205.192.5):/tmp
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
LPmudr Runs on BSD or SysV with networking. Latest version is
2.7. Designed primarily for LPMUDs. Features include
line editing, command history, auto-login and logging.
ftp.cd.chalmers.se(129.16.79.20):/pub/lpmudr
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
MUD.el Runs on GNU Emacs. Usable for TinyMUD-style muds, LPMUDs,
and MOOs. Features include auto-login, macros, logging,
cyberportals, screen mode, and it is programmable.
parcftp.xerox.com(18.85.0.2):/pub/MOO/clients
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
TinyTalk.el Runs on GNU Emacs. Latest version is 0.5. Designed primarily
for TinyMUD-style muds. Features include auto-login, macros,
logging, screen mode, and it is programmable.
ftp.tcp.com(128.111.72.60):/pub/mud/clients
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
LPmud.el Runs on GNU Emacs. Designed primarily for LPMUDs. Features
include macros, triggers, file uploading, logging, screen
mode, and it is programmable.
ftp.lysator.liu.se(130.236.254.1):/pub/lpmud/clients
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
CLPmud.el Runs on GNU Emacs. Designed primarily for LPMUDs. Similar
to LPmud.el, but with the added capability for remote
file retrieval, editing in emacs, and saving, for LPMud
wizards.
mizar.docs.uu.se(130.238.4.1):/pub/lpmud
MyMud.el Runs on GNU Emacs. Latest version is 1.31. Designed primarily
for LPMUDs and Dikus. Features include screen mode,
auto-login, macros, triggers, autonavigator, and it is
programmable.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
ftp.tcp.com(128.111.72.60):/pub/mud/clients
TINT Runs on VMS with MultiNet networking. Latest version is 2.2.
Designed primarily for TinyMUD-style muds. Features include
hiliting (whispers, pages, users), gags, file uploading,
simple macros, screen mode. See also TINTw.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
TINTw Runs on VMS with Wollongong networking. See TINT.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
ftp.tcp.com(128.111.72.60):/pub/mud/clients
DINK Runs on VMS with either Wollongong or MultiNet networking.
Similar to TINT. No longer supported by the author.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
ftp.tcp.com(128.111.72.60):/pub/mud/clients
FooTalk Runs on VMS with MultiNet networking and BSD Unix. Primarily
designed for TinyMUD-style muds. Features include screen
mode, and it is programmable. See RispTalk below.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
RispTalk Runs on BSD Unix. FooTalk with an interpreter for converting
a lispish language into footalk's language. See FooTalk above. NO KNOWN SITE
REXXTALK Runs on IBM VM. Latest version is 2.1. Designed primarily
for TinyMUD-style muds. Features include screen mode,
logging, macros, triggers, hilites, gags, and auto-login.
Allows some IBM VM programs to be run while connected to
a foreign host, such as TELL and MAIL. (Warning: Ftp-ing
the module sometimes does not work. Try emailing
SESPC381@YSUB.YSU.EDU or SESPC381@YSUB.BITNET and he
should be able to send you the module via bitnet.)
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
MUDDweller Runs on any Macintosh. Latest version is 1.1d7. Connects
to a MUD through either the communications toolbox or
by MacTCP. Usable for both LPMUDs and TinyMUD-style muds.
Current features include multiple connections, a command
history and a built-in MTP client for LPMUDs.
rudolf.ethz.ch(129.132.57.10):/pub/mud
sumex-aim.stanford.edu(36.44.0.6):/info-mac/comm
mac.archive.umich.edu(141.211.164.153):
/mac/utilities/communications
wuarchive.wustl.edu(128.252.135.4):/mirrors/info-mac/comm
Mudling Runs on any Macintosh. Latest version is 0.9b26.
Features include multiple connections, triggers,
macros, command line history, separate input and output
windows, and a rudimentary mapping system.
imv.aau.dk(129.142.28.1):/pub/Mudling
ftp.math.okstate.edu(139.78.10.6):/pub/muds/clients
MUDCaller Runs under MSDOS. Latest version is 1.00. Requires an
Ethernet card, and uses the Clarkson Packet drivers.
Does NOT work with a modem. (If you telnet in MSDOS,
you can probably use this.)
ftp.tcp.com(128.111.72.60):/pub/mud/clients
wuarchive.wustl.edu(129.252.135.4):/pub/MSDOS_UPLOADS
BSXMUD Clients These clients run on various platforms, and allow the
user to be able to see the graphics produced by BSXMUDs.
BSXMUDs are generally LPMUDs who have been hacked to
enable the sending of polygon graphics coordinates
to BSXclients, thus letting you play a graphic
LPMUD instead of just a text-based one.
For more information, contact vexar@watserv.ucr.edu.
For Amiga: requires a modem - amigaclient.lzh
For PC: requires a modem - msclient.lzh AND x00v124.zip
For X11: sources, version 3.2 - bsxclient.tar.Z
For Sun4: binary - client.sparc.tar.Z
Also available are programs to custom-draw your
own graphics for a BSXMUD: - muddraw.tar.Z
ftp.lysator.liu.se(130.236.254.1):pub/lpmud/bsx
ftp.math.okstate.edu(139.78.10.6):pub/muds/BSXstuff
Glossary of Client Terms
Auto-login Automatically logs into the game for you.
Hiliting Allows boldface or other emphasis to be applied to some
text. Often allowed on particular types of output
(e.g. whispers), or particular players. "Regexp" means
that UNIX-style regular expressions can be used to select
text to hilite.
Gag Allows some text to be suppressed. The choice of what to
suppress is often similar to hiliting (players or regular
expressions).
Macros Allows new commands to be defined. How complex a macro
can be varies greatly between clients; check the
documentation for details.
Logging Allows output from the MUD to be recorded in a file.
Cyberportals Supports special MUD features which can automatically
reconnect you to another MUD server.
Screen Mode Supports some sort of screen mode (beyond just scrolling
your output off the top of the screen) on some terminals.
The exact support varies.
Triggers Supports events which happen when certain actions on the
MUD occur (e.g. waving when a player enters the room).
(This can nearly always be trivially done on programmable
clients, even if it isn't built in.)
Programmable Supports some sort of client-local programming. Read the
documentation.
Some of these clients are more featured than others, and some require
a fair degree of computer literacy. TinyTalk and TinyFugue are
among the easiest to learn; Tcltt is more professional. Caveat Emptor.
Since many MUDders write their own clients, this list can never be
complete. As above, ask around.
Server Information
6. What is a server?
A server is a program which accepts connections, receives data, mulls
it over, and sends out some output. In the MUD world, the server keeps
track of the database, the current players, the rules, and sometimes
the time (or the 'heartbeat'). Servers are usually very large C programs
which maintain a small-to-enormous database of the objects, rooms,
players and miscellany of the MUD.
7. Where do I get servers?
Below there is a list of different types of servers, complete with
ftp sites on which they can be found. Be aware that this list is
far from complete, as new servers pop up constantly, and the
existing ones are still being developed.
8. What operating systems to servers run on?
Most servers require some form of UNIX, be it BSD or SysV. A few
servers are being ported to VMS nowadays, and there are a few which
have versions for MS-DOS and Amigas.
9. Is there anything wrong with running a server?
Because of their size and their constant computational activities,
servers can be extremely CPU-intensive and can even be crippling to any
other work done on that computer. Even if they're not CPU-intensive,
most MUDs can take up a fair amount of disk space - anywhere from
10 to 90 megs, which could impact the other users on the machine.
Do not ever run a MUD server on a machine illicitly or without express
permission from the person responsible for the machine. Many universities
and companies have strict policies about that sort of behavior which you
don't want to cross.
Of course, people who don't know any better start up illicit MUDs all the
time. Apart from the possibility of losing all your work and energy to
one press of a sysadmin's finger, there's no harm done to the player.
But we must stress: running a MUD where you shouldn't can get you into
a whole new world of hurt. Don't take the chance, it's not worth it.
10. What different servers are available?
There are probably as many MUD server types as there are MUDs. Since
everyone has their own opinions as to what MUDs should be like, and since
the server source can be edited, most MUDs have site-specific fixtures
in them. However, there are a few main protoMUDs (also called 'vanilla
versions' because they haven't been 'flavored' yet). Note that this
list is not complete, and that it may contain errors in fact or
judgement, but is deemed pretty much right as of this writing.
Corrections/additions to jds@math.okstate.edu are welcomed.
There are essentially three groups of muds:
o Combat-oriented MUDs (LP/Diku/etc)
o TinyMUD and its direct descendants, aka social-oriented MUDs
o Miscellaneous
The majority of the muds in the miscellaneous category are not
combat-oriented muds at all, and indeed many take after TinyMUD in most
things. However, as these muds are not a direct derivative of the original
TinyMUD code, I've stuck them in their own category. The authors
listed for each server are very probably not the people currently
working on that code. To find out who's currently in charge of
the code, either ftp the latest version and look for a README
file, or ask around. Directions for how to ftp and unarchive servers
can be found at the end of this FAQ.
A note on the term 'combat-oriented': this generally means that combat
is an inherent part of the culture of the mud. A flight-simulator
could be called a combat-oriented game, just as truely as your typical
shoot-em-up game could be. A 'social-oriented' mud has a different
focus, one dependent either on roleplaying social interactions (which
MAY include combat!), or on not roleplaying at all, but merely talking
with friends or other such benign things.
Combat-Oriented MUDs
--------------------
MUD The original, by Richard Bartle and Roy Trubshaw, written back
in 1978. Not available any more, except as an advanced
version now running on CompuServe under the name of
"British Legends".
AberMUD One of the first adventure-based MUDs. Players cannot build.
In later versions, I believe, a class system was added, and
wizards can build onto the database. It's named after
the university at which it was written, Aberstywyth.
Latest version is 5.21.4. Supports all the usual in
combat game design, including BSX graphics and MudWHO.
Not too big, and it will run under BSD and SYSV.
Author, contact address, and mailing list address is
iiitac@pyr.swan.ac.uk.
sunacm.swan.ac.uk(137.44.12.4):/pub/misc/AberMUD5/SOURCE
LPMUD The most popular combat-oriented MUD. Players cannot build.
Be warned, though: LPMUD servers version 3.* themselves are
very generic - all of the universe rules and so forth are
written in a separate module, called the mudlib. Most
LPMUDs running are written to be some sort of combat system,
which is why I've classified them here, but they don't
have to be! Wizards can build onto the database, by means
of an object-oriented C-like internal language called LP-C.
It's named after its primary author, Lars Penj|. Latest
version is 3.2. Fairly stable, and size varies from
medium to large. For further information, email to
amylaar@mcshh.hanse.de.
ftp.cd.chalmers.se(129.16.79.20):/pub/lpmud
lysator.liu.se(130.236.254.1):/pub/lpmud
worf.tamu.edu(128.194.51.189):/pub/lpmud
calvin.nmsu.edu(128.123.35.150):/pub/mud/src
netserv1.its.rpi.edu(128.113.1.5):/pub-write/lpmud
ucbvax.berkeley.edu(128.32.133.1):/pub/games/lpmud
There is a port of 3.1.2 for MSDOS, that requires at least
a '386 to run. It accepts connections from serial ports.
ftp.cd.chalmers.se(129.16.79.20):/pub/lpmud/msdos
There is a port of 3.1.2 for Amigas, called amud. Binaries
and source are available. For further information email
to mateese@ibr.cs.tu-bs.de.
ftp.cd.chalmers.se(129.16.79.20):/pub/lpmud/amud
There are several popular mudlibs available, along with a
few variants of the "standard" LPMUD code. I hope to have
a section devoted to them here soon. Contributions emailed
to jds@math.okstate.edu are welcomed.
DikuMUD Newer than LPMud, and gaining in popularity. Almost identical
from the players' point of view. Uses a guild system instead
of a straight class system. Different classes get different
tricks specific to that class at various levels. Wizards
can add on to the database, but there is no programming
language, as in LP. It's named after the university at
which it was written.
coyote.cs.wmich.edu(141.218.40.40):/pub/Games/Diku
ucbvax.berkeley.edu(128.32.133.1):/pub/games/dikumud
KMUD Still under development. KMUD is similar to LPMUD in
feel, but only runs on PCs. It does have some on-line
building commands. It accepts connections from serial
ports (requires a FOSSIL driver), and through TCP/IP
telnet protocol. Beta versions (with source code)
are available.
NO KNOWN SITE
1001 Still partially in development. 1001 is similar to
DikuMUD in feel and design, but runs only on PCs.
Multitasking is required, and a '386 is recommended.
It's designed for use primarily with multiline BBS
systems, and supports most BBS software.
Author is Jim Dugger. Latest version is 1.03.
Available on FidoNet 1:3814/2, as well as
ftp.math.okstate.edu(139.78.10.6):/pub/muds/servers
YAMA PC mud writing system, using waterloo wattcp. Runs on a
640K PC/XT or better. Runs best with about a 1Mb ram disk,
but is fine without. A seperate windows version (yamaw)
runs under windows and allows you to run a mud on a 286
or higher without taking over the machine.
sunacm.swan.ac.uk(137.44.12.4):/pub/misc/YAMA
UriMUD Developed from an LPMud2.4.5, the code structure is
very similar. Features include better speed,
flexibility, stronger LPC, and the ability to
handle multiple mudlibs under one parser.
Latest version is 2.3.
netcom.com(192.100.81.100):/pub/urimud
TinyMUD-style MUDs
------------------
TinyMUD The first, and archetypical, socially-oriented MUD. It
was inspired by and looks like the old VMS game Monster,
by Rich Skrenta. Players can explore and build, with the
basic @dig, @create, @open, @link, @unlink, @lock commands.
Players cannot teleport, and couldn't use @chown or set
things DARK until later versions. Recycling didn't exist
till the later versions, either. It's called 'Tiny'
because it is - compared to the combat-oriented MUDs.
Original code written by Jim Aspnes. Last known version
is 1.5.5. Not terribly big, and quite stable.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/servers
impaqt.drexel.edu(129.25.10.3):
/pub/files/unix/games/MUD/tinymud
There is a PC port of TinyMUD, along with some extra
code. It accepts connections from serial ports.
NO KNOWN SITE
There is a modified version of TinyMUD called PRISM,
that works for PCs, Atari STs, and most Unixes. It
also comes with a internal BSX client for MSDOS.
lister.cc.ic.ac.uk(129.31.80.167):/pub/prism
TinyMUCK v1.* The first derivative from TinyMUD. Identical to TinyMUD,
except that it added the concept of moveable exits, called
@actions. Also introduced the JUMP_OK flag, which allows
players to use @teleport, and @recycle, which TinyMUD later
added. Its name, MUCK, is derived from MUD, and means
nothing in particular. Original code written by Stephen
White. Latest stable verion is 1.2.c&r, which brought
TinyMUCKv1 up to date with later TinyMUD things. Not
terribly big.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/servers
TinyMUSH The second derivative from TinyMUD. Also identical to TinyMUD,
with the addition of a very primitive script-like language.
Introduced JUMP_OK like TinyMUCK, and has recycling, except
it is called @destroy. Also introduced the concept of
PUPPETs, and other objects that can listen. In later
versions the script language was extended greatly, adding
math functions and many database functions. In the latest
version, 2.0.*, it's gone to a disk-basing system as well.
Its name, MUSH, stands for Multi-User Shared Hallucination.
Original code written by Larry Foard. The latest non-
disk-based version is PennMUSH1.50, which is quite similar
to 2.0 from the user's point of view. Both the disk-based
version and the non-disk-based version are being developed
at the same time. TinyMUSH is more efficient in some ways
than TinyMUD, but winds up being larger because of programmed
objects. Version 2.0 in general uses less memory but a
great deal more disk space. 2.0 may also be able to be
run under VMS, as well as both BSD and SysV UNIX.
Most recent version is 2.0.9p10, but last known stable
version is 2.0.8p4.
primerd.prime.com(129.122.132.150):/pub/games/mud/tinymush
caisr2.caisr.cwru.edu(129.22.24.22):/pub/mush
ftp.tcp.com(128.111.72.60):/pub/mud/mush
TinyMUCK v2.* TinyMUCKv1.* with a programming language added. The language,
MUF (multiple user forth), is only accessible to people with
the MUCKER flag. Changed the rules of the JUMP_OK flag
somewhat, to where it's nice and confusing now. MUF is
very powerful, and can do just about anything a wizard can.
Original version 2.* code written by Lachesis. Latest
version is 2.3b, with several varieties (FBMUCK and
DaemonMUCK 0.14 the most common).
Can be quite large, especially with many programs.
Mostly stable.
ftp.tcp.com(128.111.72.60):/pub/mud/tinymuck
TinyMUSE A derivative of TinyMUSH. Many more script-language
extensions and flags. Reintroduced a class system,
a-la combat-oriented MUDs.
Latest version is 1.4, but it's not very stable.
chezmoto.ai.mit.edu(18.43.0.102):/tinymuse
TinyMAGE The bastard son of TinyMUSH and TinyMUCK. It combines
some of MUSH's concepts (such as puppets, @adesc/@asucc,
several programming functions, and a few flags) with
TinyMUCK2.x. Interesting idea, really busted code.
Latest version is 1.1.2.
ftp.tcp.com(128.111.72.60):/pub/mud/incoming
Miscellaneous
-------------
UberMUD The first MUD where the universe rules are written
totally in the internal programming language, U. The
language is very C/pascal-like. The permissions system
is tricky, and writing up every universe rule (commands
and all) without having big security holes is a pain.
But it's one of the most flexible muds in existance.
Great for writing up neat toys. It's also disk-based.
Original code written by Marcus J Ranum. Latest version
is 1.13. Small in memory, but can eat up disk space.
Quite stable.
decuac.dec.com(192.5.214.1):/pub/mud
ftp.white.toronto.edu(128.100.2.160):/pub/muds/uber
ftp.math.okstate.edu(139.78.10.6):/pub/muds/servers
MOO An Object-Oriented MUD. Unfortunately, the first few
versions weren't fully object oriented. Later versions
fixed that problem. There is a C-like internal programming
language, and it can be a bit tricky. Original code
written by Stephen White. Last version is 2.0a.
NO KNOWN SITE
LambdaMOO An offshoot of MOO. Added more functionality, many
new features, and a great deal more stability, in a
general rewrite of the code. This is the only version
of MOO that is still being developed, by Pavel Curtis.
Latest version is 1.7.0.
parcftp.xerox.com(13.1.64.94):/pub/MOO
TeenyMUD A TinyMUD clone, written from scratch. Its main feature
is that it is disk based. Original code written by
Andrew Molitor. Latest version is 1.3a. Very small,
and mostly stable.
fido.econ.arizona.edu(128.196.196.1):/pub
SMUG Also known as TinyMUD v2.0. It has an internal programming
language, and it does have some inheritance. Surprisingly
similar to MOO in some ways. SMUG stands for Small Multi
User Game. Original code written by Jim Aspnes.
impaqt.drexel.edu(129.25.10.3):/pub/files/unix/games/MUD/smug
ftp.tcp.com(128.111.72.60):/pub/mud/smug
wuarchive.wustl.edu(128.252.135.4):
/pub/archives/comp.sources.games/vol11/tinymud2
UnterMUD A network-oriented MUD. It's disk-based, with a variety
of db layers to choose from. An UnterMUD can connect
directly to other UnterMUDs, and players can carry
stuff with them when they tour the Unterverse. This can
be a bit baffling to a new user, admittedly, but those
people already familiar with the old cyberportals and
how they work (invented way back with the original TinyMUD)
will adjust to the new real cyberportals easily. There
is both a primitive scripting language and much of the
U language from UberMUD built in, as well as a combat
system that can be compiled in if wanted. The parsing
can be a bit odd, especially if you're used to the
TinyMUD-style parser. Unter is also the only MUD that
can run under BSD Unix, SysVr4 Unix, and VMS with MultiNet
networking, with little to no hacking. Original code
written by Marcus J Ranum.
Latest version is 2.1. Small in memory, but can eat up
a lot of disk space.
ftp.math.okstate.edu(139.78.10.6):/pub/muds/servers
decuac.dec.com(192.52.214.1):/pub/mud
ftp.tcp.com(128.111.72.60):pub/mud/unter
Note: just because we say something's available doesn't mean we have it.
Please don't ask us; ask around for ftp sites that might have them, or
try looking on ftp.tcp.com (128.111.72.60) or ftp.math.okstate.edu
(139.78.10.6).
General Information
11. What do I do if my client/server won't compile?
Your first best bet is to check out the documentation and see if someone
is listed as 'supporting' (i.e. generally responsible for) the program.
If they are, send them a short, well-written e-mail note explaining your
hardware and software completely as well as a transcript of the error.
Do not post to the internet unless all other realistic options have been
considered and taken -- generally speaking, most readers will not be
interested in your dilemma and may get upset that you're wasting their
time. Since MUDs have probably been compiled on every single platform
since the Cyber 3000, there's a good chance that asking around the
subculture will get you the answers you crave. Do not mail me. I
probably won't know.
12. Should I read the documentation of whatever client or server I select?
Yes.
13. What is FTP, and how do I use it?
FTP stands for File Transfer Protocol, and is a way of copying files
between networked computers. The best way to learn about ftp is
to get the FTP FAQ, by emailing mail-server@rtfm.mit.edu with
send usenet/news.answers/ftp-list/faq
in the body of the message.
Not all ftps are alike, but here's a sample session:
% ftp ftp.math.okstate.edu
Connected to ftp.math.okstate.edu.
220 ftp.math.okstate.edu FTP server (SunOS 4.1) ready.
Name (ftp.math.okstate.edu:jds): ftp <-- use 'ftp' as your login
331 Guest login ok, send ident as password.
Password: <-- use your email addr as pwd
230 Guest login ok, access restrictions apply.
ftp> cd pub/muds/clients <-- how to change directories
250 CWD command successful.
ftp> dir <-- ls also works
200 PORT command successful.
150 ASCII data connection for /bin/ls (139.78.10.6,4011) (0 bytes).
total 2310
-rw-r--r-- 1 4002 4002 34340 Feb 6 1992 amigaclient.lzh
...etc etc...
-rw-r--r-- 1 4002 4002 43093 Dec 13 1991 tinytalk.117.shar.Z
226 ASCII Transfer complete.
2631 bytes received in 0.7 seconds (3.6 Kbytes/s)
ftp> bin <-- VERY IMPORTANT! binary transfers
200 Type set to I.
ftp> get tinytalk.117.shar.Z <-- get filename
200 PORT command successful.
150 ASCII data connection for tinytalk.117.shar.Z (139.78.10.6,4012) (43093 bytes).
226 ASCII Transfer complete.
local: tinytalk.117.shar.Z remote: tinytalk.117.shar.Z
43336 bytes received in 0.28 seconds (1.5e+02 Kbytes/s)
ftp> bye <-- how to quit ftp
221 Goodbye.
%
Now that you've successfully ftped a file, you must unarchive it. There
are many ways of archiving files; so many that they couldn't possibly
all be listed here. In general, though, if a file ends in:
.Z <-- uncompress filename
.z <-- gunzip filename
.tar <-- tar -xvf filename
.shar <-- sh filename
.zip <-- unzip filename
Generally, once you've unarchived your client or server, you must still
compile it. This varies widely depending on the system you're on and
the particular client or server. Your best bet is to look for a README
or INSTALLATION file or something equally obvious, and then if you're
still unsure, ask someone locally to help you out.
FREQUENTLY ASKED QUESTIONS: Basic Information on RWHO and "mudwho"
This is part 3 in a 3 part series of FAQs.
Table of Contents
-----------------
1. What is RWHO?
2. How Does It All Work?
3. Where Can I Get This Stuff?
4. Where Are Some RWHO Servers?
1. What is RWHO?
RWHO stands for 'Remote WHO'. It's a way of getting a WHO list from
a MUD, without even having to connect to that MUD at all. Anyone
can get this output from a RWHO server (an 'mwhod'), by using straight
telnet to connect to a certain port (6889), or by using the client program
'mudwho'. RWHO servers talk to other mwhods, passing information around,
and are talked to directly by some MUDs, receiving information from them.
Any one mwhod keeps track of several MUDs, plus storing information passed
it from other mwhods. Only MUDs that have the RWHO routines compiled in
will be able to send their WHO list info to a mwhod. UnterMUDs have this
capability built in; other MUDs have to have the routines installed first.
The RWHO routines have been installed into TinyMUSH, TinyMUCK, LPMUD,
DikuMUD, and AberMUD, without encountering any difficulty.
2. How Does It All Work?
'mwhod' is the RWHO server that runs on a particular host and
keeps a list of known MUDs. It is initially primed with a list of "trusted"
MUDs and passwords used for authentication, and will accept information
about who is logged into those MUDs. The server also has a notion of
a "peer" server, which can transfer it (occasionally) a copy of all of
its list of who is logged on, and where. The idea is that the whole
MUDding community could probably be served pretty well by about 5 peer
mwhods that kept each other up to date about what each one is seeing.
Communication between mwhods (and server updates sent to mwhods)
is done with UDP datagrams, since they're fast, nonblocking, and
throw-away. (RWHO information is considered to be interesting but not
vital information, if you get my drift). Each MUD server only sends
updates to a single mwhod, which may then propagate that information
to its peers. This is done within the MUD server as follows:
- whenever the server boots, it sends a "hi there" packet to
the mwhod, telling it that it's up and running.
- whenever a player connects, it sends a "so and so is here"
packet to the mwhod, telling it that the user has connected.
- whenever a player disconnects, it sends a "so and so left"
packet to the mwhod, telling it to delete the entry.
- every so often ("so often" being defined as a time agreed
upon by the mwhod's owner, and the MUD's wizard, usually
every 5 minutes or so) the MUD sends a "hi there" packet
and a complete list of everyone that is on, just to refresh
the mwhod's idea of who is logged into that MUD.
If a user connects to a specific port (6889) of a host machine
running an mwhod they are given a formatted dump of the mwhod's current
table of MUDs and players, and then disconnected. "mudwho" is a simple
little program that contacts an mwhod and downloads this information.
Ideally, the functionality of "mudwho" would be built into a player's
client software, for ease of use. Two handy options can be used by
"mudwho", if the netlag to the mwhod server isn't too bad. The options
are "-u <username>", and "-m <mudname>". If received before the timeout,
the mwhod will then only dump WHO list information for the specified
player or MUD.
The mwhod does some clever stuff as far as eventually timing
information about of its tables - for example, if it hears absolutely
nothing from a MUD for a certain amount of time, it will mark the MUD
as down. Player entries are expired similarly. The design is based on
the idea that we'll use UDP to just fling information out and hope it
sticks, and then let the recipient clean it up, rather than to develop
a more complex protocol based on TCPs and timeouts. To prevent a packet
circular send situation, each entry that is sent is given a "generation"
number, which is incremented by one each time it is forwarded along. In
this manner, a MUD server might send a "so and so is here" (generation
zero) to its local mwhod. The local mwhod will eventually send a copy to
any peers it may have (generation one), and so forth. Part of the initial
table that an mwhod uses to establish what peers it trusts contains a
generation value, and it will neither accept nor propagate information
to a specific peer that is of a higher generation value. This way, a
"tree" of servers could theoretically be constructed, with the highest
level one having a total view of a large MudIverse.
3. Where Can I Get This Stuff?
The client program "mudwho" can be ftp'd from ftp.math.okstate.edu
(139.78.10.6), in pub/muds/clients. The shar file contains both
mudwho.c and a README file, listing a few mwhod sites. The plain "mudwho.c"
file can be found at decuac.dec.com (192.5.214.1).
The RWHO routines can be ftp'd from decuac.dec.com (192.5.214.1),
in pub/mud. Included is a HOW_TO file, which describes how to plug
the routines into a MUD server, and also where to ask for a mwhod to use.
The mwhod program itself can also be found on decuac, but there is
currently little need for another one running in the USA. There is, however,
only one running in Europe, and further expansion may need to be made in
that area.
4. Where Are Some RWHO Servers?
Currently, all of these servers talk to each other, so what one knows,
the rest will know, with the exception of the mwhod in Germany, which only
talks to the mwhod on riemann.math.okstate.edu (so only riemann has
the RWHO information from Europe currently). At any one time, there's an
average of 20 muds, of various types, talking to mwhods.
Site IP Port Admin
------------------------------------------------------------------------------
riemann.math.okstate.edu 139.78.1.15 6889 jds@math.okstate.edu
amber.ecst.csuchico.edu 132.241.1.43 6889 warlock@ecst.csuchico.edu
nova.tat.physik
.uni-tuebingen.de 134.2.62.161 6889 gamesmgr@taurus.tat.physik
.uni-tuebingen.de
------------------------------------------------------------------------------
This posting has been generated as a public service. If you have any
suggestions, questions, additions, comments or criticisms concerning this
posting, contact Jennifer Smith, aka Moira (jds@math.okstate.edu).
Other Frequently Asked Questions (FAQ) postings contain information
dealing with MUDs, MUDding, clients, servers, and FTP sites. While these
items aren't necessary, they make the game much more playable. I'd also
like to thank Marcus J Ranum (mjr@decuac.dec.com) for writing such a
wonderful program (and decent docs), and everyone else for helpful comments
and suggestions.
The most recent versions of these FAQs are archived on ftp.math.okstate.edu
(139.78.10.6) in pub/muds/misc/mud-faq, plus on rtfm.mit.edu(18.170.0.226)
in the news.answers archives. Have fun! - Moira
--
Jennifer Smith
jds@math.okstate.edu